…imeout coverage

f8d8eb5 test: add addr-fetch timeout connection coverage in p2p_addrfetch.py (Jon Atack)
9321086 test: add assert_getpeerinfo method and coverage in p2p_addrfetch.py (Jon Atack)

Pull request description:

  This patch adds additional addr-fetch peer connection state and timeout coverage as a follow-up to bitcoin#22096.

ACKs for top commit:
  Saviour1001:
    Tested ACK <code>[f8d8eb5](https://github.com/bitcoin/bitcoin/pull/22568/commits/f8d8eb5fdaa93b6e5b77fd901b94927dc3a0473e)</code>
  mzumsande:
    Code review ACK f8d8eb5

Tree-SHA512: 9a13a705d1da6b308d6dcbc6930575205e2e88bfe9f2e7cb4e0c4c40d26538430e6b02c6c772d0cee64e534777348291469a139f99afbf9d4f93f31b9e7b0818
Signed-off-by: Vijay <[email protected]>

…limits for packages

accf3d5 [test] mempool package ancestor/descendant limits (glozow)
2b6b26e [test] parameterizable fee for make_chain and create_child_with_parents (glozow)
313c09f [test] helper function to increase transaction weight (glozow)
f8253d6 extract/rename helper functions from rpc_packages.py (glozow)
3cd663a [policy] ancestor/descendant limits for packages (glozow)
c6e016a [mempool] check ancestor/descendant limits for packages (glozow)
f551841 [refactor] pass size/count instead of entry to CalculateAncestorsAndCheckLimits (glozow)
97dd1c7 MOVEONLY: add helper function for calculating ancestors and checking limits (glozow)
f95bbf5 misc package validation doc improvements (glozow)

Pull request description:

  This PR implements a function to calculate mempool ancestors for a package and enforces ancestor/descendant limits on them as a whole. It reuses a portion of `CalculateMemPoolAncestors()`; there's also a small refactor to move the reused code into a generic helper function. Instead of calculating ancestors and descendants on every single transaction in the package and their ancestors, we use a "worst case" heuristic, treating every transaction in the package as each other's ancestor and descendant. This may overestimate everyone's counts, but is still pretty accurate in the our main package use cases, in which at least one of the transactions in the package is directly related to all the others (e.g. 1 parent + 1 child, multiple parents with 1 child, or chains).

  Note on Terminology: While "package" is often used to describe groups of related transactions _within_ the mempool, here, I only use package to mean the group of not-in-mempool transactions we are currently validating.

  #### Motivation

  It would be a potential DoS vector to allow submission of packages to mempool without a proper guard for mempool ancestors/descendants. In general, the purpose of mempool ancestor/descendant limits is to limit the computational complexity of dealing with families during removals and additions. We want to be able to validate multiple transactions on top of the mempool, but also avoid these scenarios:

  - We underestimate the ancestors/descendants during package validation and end up with extremely complex families in our mempool (potentially a DoS vector).
  - We expend an unreasonable amount of resources calculating everyone's ancestors and descendants during package validation.

ACKs for top commit:
  JeremyRubin:
    utACK accf3d5
  ariard:
    ACK accf3d5.

Tree-SHA512: 0d18ce4b77398fe872e0b7c2cc66d3aac2135e561b64029584339e1f4de2a6a16ebab3dd5784f376e119cbafc4d50168b28d3bd95d0b3d01158714ade2e3624d
Signed-off-by: Vijay <[email protected]>

… functional tests for efficiency

47c48b5 test: only use verbose for getrawmempool when necessary in functional tests (Michael Dietz)
7734971 test: use getmempoolentry instead of getrawmempool in functional tests when appropriate (Michael Dietz)
86dbd54 test: improve mempool_updatefrom efficiency by using getmempoolentry for specific txns (Michael Dietz)

Pull request description:

  I don't think this changes the intention of the test. But it does shave ~30 seconds off the time it takes to run. From what I've seen our CI `macOS 11 native [gui] [no depends]` runs `mempool_updatefrom.py` in ~135 seconds. After this PR it should run in ~105 seconds

  I noticed this improvement should probably be made when testing performance/runtimes of bitcoin#22698. But I wanted to separate this out from that PR so the affects of each is decoupled

  Edit: The major change in this PR is improving mempool_updatefrom.py's runtime as this is a very long running test. Then made the same efficiency improvements across all the functional tests as it made since to do that here

ACKs for top commit:
  theStack:
    Tested ACK 47c48b5

Tree-SHA512: 40f553715f3d4649dc18c2738554eafaca9ea800c4b028c099217896cc1c466ff457ae814d59cf8564c782a8964d8fac3eda60c1b6ffb08bbee1439b2d34434b
Signed-off-by: Vijay <[email protected]>